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Resume 

Un langage de programmation qui se veut utile doit etre capable 
d'exprimer des programmes qui profitent des services et des mecanismes 
de communication supportes par le systeme d'exploitation. Nous exam- 
inons dans cet article le probleme de la programmation d' applications 
Win32 dites "natives" sous le systeme d'exploitation Windows avec le 
langage fonctionnel Standard ML. Nous introduisons une infrastructure 
basee sur le langage d'interfaces IDL et sur une interface aux fonctions 
etrangeres minimaliste pour explorer le support de l'API Win32 et de la 
technologie COM dans le contexte de Standard ML. 



1. Introduction 

L'utilite d'un langage de programmation moderne ne se juge pas uniquement a 
la lumiere de la qualite intrinseque du langage. Comme Findique Wadler [13], 
un langage doit de plus posseder un environnement de programmation capable 
d'exprimer des programmes qui coexistent avec un modele d' application 
supporte par le systeme d'exploitation. Ce modele d' application peut inclure 
des services fournis par le systeme d'exploitation, comme l'interface-usager et 
la gestion d'evenements, et aussi inclure des mecanismes de communication et 
des "contrats" entre differentes applications sous un meme systeme et par-dela 
un reseau. 
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Dans cet article, nous examinons un tel probleme en detail. Specifiquement, 
nous etudions la programmation d' applications dites natives Win32 sous un 
systeme Windows avec le langage fonctionnel Standard ML (SML) [7]. Nous 
nous concentrons sur la communication avec le systeme d' exploitation via 
FAPI Win32, et la communication avec d'autres applications via F interface 
COM (Components Object Model). 

Plusieurs buts guident notre entreprise. Tout d'abord, nous voulons unifier 
les differentes visions du support du systeme d' exploitation Windows, en 
fournissant une infrastructure pour exprimer ces differentes visions. Nous 
englobons le travail effectue par l'equipe du langage de programmation Haskell 
[9, 2], c'est-a-dire le scripting de composants COM a partir d'un langage 
fonctionnel, et le completons en fournissant acces a FAPI Win32, necessaire 
pour le developpement de programmes Windows. L'utilisation du langage 
SML apporte des avantages notables compare a l'utilisation de Haskell dans 
ce contexte. Principalement, le systeme de modules de SML permet de 
capturer de fagon abstraite la notion d' interface avec le systeme Win32, tout 
en permettant des implantations differentes pour differents compilateurs. Notre 
second but, plus pedagogique, est la presentation informelle de la methodologie 
moderne d'utilisation de composants telle qu'implantee dans Fenvironnement 
Windows. Cet article donne un survol de notre project, en montrant qu'avec 
les outils appropries, il est simple de fournir une interface utilisable vers FAPI 
Win32, et montre comment le reste de F infrastructure Windows peut suivre. 
Un prototype du systeme existe, et est implante avec le compilateur Standard 
ML of New Jersey [1]. 

Nous imposons la contrainte majeure de garder la generation d' applications 
Win32 entierement en SML. Nous voulons eviter de devoir programmer des 
aspects de Fapplication en C 1 , et nous irons meme jusqu'a desirer eviter de 
requerir un compilateur C. Ceci nous permet d'obtenir un systeme relativement 
ferme, simplifiant l'utilisation et permettant une interactivite toujours possible 
avec les environnements SML courants. 

II est utile de remarquer que la plupart des remarques que nous allons 
effectuer sur la communication avec le systeme d' exploitation et l'utilisation 
des mecanismes de composants peuvent etre generalisees, notablement aux 
composants CORBA disponibles sur plusieurs systemes. Nous n' allons pas 
nous attarder sur de telles generalisations ici. De meme, ce travail se generalise 
immediatement a d'autres langages, notablement OCAML [5]. 

Le plan general de Particle est le suivant. Nous allons tout d'abord decrire 
la structure generate de FAPI Win32 et de la technologie COM, ainsi que 
les diverses derivations telles que OLE et ActiveX. Nous decrivons ensuite 
une interface aux fonctions etrangeres minimaliste, qui nous permettra de 
communiquer avec le systeme d' exploitation. Ensuite, nous parlerons dTDL, 

I II peut etre desirable de programmer des parties de ['application en C, mais ce ne devrait 
jamais etre necessaire. 
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le langage utilise pour decrire les interfaces de l'APl Win32 et d'objets COM, 
et de l'outil qui permet de generer du code SML a partir d'une description IDL. 
Nous montrons comment interfacer 1' API Win32 dans ce contexte, et comment 
utiliser et creer des objets COM. Finalement, nous allons discuter certaines 
generalisations que nous allons explorer dans le futur. 

2. La programmation Win32 

L' API Win32 est 1' ensemble des fonctions systemes fournies par les differents 
systemes d' exploitation 32 bits de Microsoft 2 . Ces fonctions sont distributes 
dans des librairies dynamiques (dynamic link libraries ou dll) qui forment le 
coeur des systemes d' exploitation Windows. 

La fonctionalite de 1' API peut se decomposer en sept grandes classes: 

• gestion des fenetres; 

• interface graphique; 

• controles communs; 

• acces au shell; 

• services du systeme; 

• services de reseau; 

• internationalisation; 

II n'est pas utile de fournir Faeces a toutes ces fonctions. Par exemple, la 
gestion de la memoire est automatique en SML; la gestion des entrees/sorties 
est fournie par la Basis Library, ainsi que les services de reseaux et 
certains services du shell. Nous nous concentrons ici sur les fonctions 
de gestion des fenetres, de F interface graphique et certaines fonctions de 
service. Les librairies qui nous interessent sont principalement user32 . dll, 
gdi32 .dll et kernel32 .dll. 

LAPI Win32 est intrinsequement lie a une structure particuliere de 
programmes, que nous revisons ici. Un programme Win32 se compose d'un 
point d'entree appele WinMain. Le role de cette fonction est d'initialiser 
F application, typiquement en enregistrant differentes classes de fenetres 
utilisees. Lenregistrement d'une fenetre necessite la definition d'une fonction 
callback qui va traiter les messages addresses a la fenetre. Cette fonction de 
traitement de messages est la fonction principale de toute application Win32. II 

2 En fait, Windows NT et Windows 95 implantent des sous-ensembles un tant soit peu differents 
de l'API Win32. Ces differences ne nous concernerons pas. 
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peut exister plusieurs fonctions de traitement de messages si plusieurs fenetres 
sont exposees par 1' application — une fonction par fenetre est la regie. 

Plutot que d'accumuler ici des details ininteressants, nous referons le 
lecteur a un ouvrage tel que [8] pour un vision en profondeur de la 
programmation Win32. 

2.1. COM 

La technologie moderne des systemes d' exploitation Windows pour la 
reutilisation de code et la distribution de librairies converge vers la technologie 
COM [6, 12]. COM est une interface binaire, et repose sur un minimum de 
principes simples, permettant une expressivite de concept impressionante. 

L'idee de base sous-jacente a COM est la notion d'une interface vers un 
objet. Une interface est une vue d'un composant, et correspond simplement a 
un tableau de pointeurs de fonctions (methodes). Etant donne une interface et 
un objet COM, il est possible de questionner l'objet pour savoir s'il supporte 
F interface consideree. Si F interface est supportee, un pointeur vers F interface 
est retourne, et a travers ce pointeur il est possible d'invoquer les methodes 
implantees par Finterface. 

L' identification d'objets COM et d'interfaces s'effectue a Faide d'iden- 
tificateurs uniques (GUID): un identificateur de classe (CLSID) est utilise 
pour parler d'un objet COM en particulier, et un identificateur d'interface 
(IID) pour parler d'une interface particuliere. II est important de noter que 
le CLSID d'un objet COM fait partie de sa description formelle. Installer 
un objet COM sur un systeme ajoute son CLSID a la liste maintenue dans 
le Registry, et de meme pour les interfaces implantees par l'objet. Utiliser 
un objet COM requiert le CLSID de l'objet en question, ainsi qu'un IID 
correspondant a Finterface initiale que Fon voudrait obtenir. Par exemple, 
la fonction Win32 CoCreatelnstance prend un CLSID et un IID en 
arguments, cree une instance de l'objet en question et retourne un pointeur 
vers Finterface correspondante, si elle est supportee par l'objet. 

Une interface speciale, Finterface IUnknown, est Finterface de laquelle 
toutes les interfaces heritent, et doit etre supportee par tout objet COM. Cette 
interface est definie ainsi en IDL, un langage pour specifier les interfaces (voir 
Section 4): 

interface IUnknown { 

HRESULT Querylnterf ace ( [in] const IID& iid, 

[out,iid_is (iid)] void **ppv) ; 

unsigned long AddRef (); 
unsigned long Release (); 

} 

La fonction la plus interessante est la premiere. Les deux autres fonctions ont 
trait a la gestion de la memoire de l'objet. La fonction Query Interface 
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nous permet, donne une interface, d'acceder a une autre interface via son 
IID. Puisque toutes les interfaces heritent de IUnknown, toutes les interfaces 
fournissent la fonction Querylnterf ace. 

Nous avons pratiquement termine la description de la technologie COM, 
tout au moins du point de vue de Futilisateur. II y a quand me me beaucoup de 
details a considerer, notablement pour ce qui a trait a la gestion de la memoire 
et de la duree de vie des objets COM, ainsi que des conventions a respecter, tels 
que Fidee qu'effectuer un Querylnterf ace sur une interface quelconque 
d'un objet donne pour Finterface IUnknown doit retourner le meme pointeur, 
permettant Futilisation de Finterface IUnknown comme identificateur utile 
pour comparer l'identite d'objets COM. Le lecteur interesse par de tels details 
se devra de lire un manuel dans la veine de [12]. 

Les technologies dites avancees de Microsoft sont toutes baties sur 
les fondations fournies par les objets COM et la notion d'interface. 
Ces technologies sont simplement des specifications d' interfaces que des 
composants doivent implanter pour interagir avec le systeme. Nous revisons ici 
de maniere informelle les plus importantes, c'est-a-dire DCOM, Automation, 
OLE et ActiveX. 

2.2. DCOM 

DCOM est une extension de COM qui permet aux serveurs d'objets COM 
de vivre sur une autre machine du reseau. Une communication de type RPC 
(Remote Procedure Call) permet d'interagir avec les objets ainsi crees. 

2.3. Automation 

La technologie Automation permet de communiquer de maniere interpreted 
et dynamique avec un objet COM. Un objet COM supporte Automation s'il 
implante Finterface IDispatch: 

interface IDispatch : IUnknown { 

HRESULT GetTypelnf oCount ([out] UINT* pctinfo); 
HRESULT GetTypelnfo ([in] UINT iTInfo, 
[in] LCID lcid, 
[out] ITypelnfo **ppTInfo) ; 
HRESULT GetlDsofNames ([in] const IIDS riid, 

[in,size_is (cNames)] LPOLESTR* rgszNames, 
[in] UINT cNames, 
[in] LCID lcid, 

[out, size_is (cNames)] DISPID* rgDispId) ; 
HRESULT Invoke ([in] DISPID dispIdMember, 
[in] const IID& riid, 
[in] LCID lcid, 
[in] WORD wFlags, 

[in, out] DISPPARAMS* pDispParams, 
[out] VARIANT* pVarResult, 
[out] EXCEPINFO* pExcepInfo, 
[out] UINT* puArgErr) ; 
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} 

Ces methodes permettent d'appeler certaines fonctions en fournissant leur 
nom sous forme de chaine de caracteres. La methode Get IDsof Names 
transforme cette chaine de caracteres en DISPID, un entier correspondant a 
la fonction, si elle existe. Ce DISPID est passe a la methode Invoke avec les 
parametres a passer a la fonction. 

Les fonctions que Invoke peut appeler (la dispinterface en langue 
COM), sont arbitrages et dependent de l'implantation de Invoke pour 
une interface donnee. Un des aspects le plus interessant d' Automation 
concerne l'implantation d'interfaces dites dual, c'est-a-dire d'interfaces COM 
dont les methodes peuvent egalement etre invoquees de maniere dynamique. 
Une interface dual derive non pas de IUnknown, mais de IDispatch. 
L'implantation de Invoke pour cette interface est telle que sa dispinterface 
correspond aux methodes de 1' interface. Ceci permet d'acceder aux methodes 
d'une interface de maniere directe via les mecanismes de COM ou interpreted 
via les mecanismes d' Automation. 

Une des restrictions imposees par Automation concerne le type des 
parametres passes par 1' interface de Invoke. Les parametres doivent 
etre de type VARIANT, une union des types de bases connus du systeme. 
Ceci implique que les fonctions invoquees par Invoke doivent verifier 
dynamiquement que leurs arguments ont un type correct. II n' existe pas de 
moyen automatique pour verifier que tout est correct lors de l'appel de la 
fonction. Les librairies de types (type libraries) allegent ce fardeau, mais nous 
ne nous y attarderons pas dans cet article. 

Notons enfin que Automation est le mecanisme principal pour la 
distribution de composants vers des langages tels que Visual Basic. 

2.4. OLE 

OLE est un ensemble d'interfaces COM standardises, ayant principalement 
rapport a des notions d'interfaces-usager. Celles-ci incluent les notions 
suivantes: documents composes, activation en place, drag and drop. OLE 
definit une interface IDataObject qui permet de transferer des informations 
entre applications, par exemple par le biais du Clipboard, ou de drag and drop. 

Une application qui veut implanter le drag and drop doit fournir au 
systeme d' exploitation un Drop Target Object avec lequel le systeme va 
communiquer lorsque l'usager traine un icone sur l'application. Cet objet 
est un objet COM qui implante l'interface OLE IDropTarget, et qui 
s'enregistre aupres du systeme via la fonction RegisterDragDrop de 
l'API Win32. Lorsque un objet est traine sur l'application, une methode 
de IDropTarget de l'application est appelee, qui se voit passer un objet 
IDataOb j ect representant l'information trainee. 
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2.5. ActiveX 

Le terme "ActiveX" est le terme le plus sur-employe de la litterature, apres le 
terme "visuel". ActiveX est une extension de la technologie OLE, permettant 
a des applications OLE d'interagir avec et par-dela l'lnternet. D'autre part, 
ActiveX Controls est le nouveau nom de ce qui etait auparavant appele 
OLE Controls , derives des controles VBX de Visual Basic. lis permettent 
l'implantation de controles, qui sont une generalization des fenetres-enfants 
fournies par Win32, comme par exemple le controle d'edition (Edit Control). 

Finalement, ActiveX Scripting denote la technologie qui permet a une 
application d'executer du code interprets en appelant un evaluateur externe, 
tel qu'un interpreteur JavaScript ou Visual Basic. 

3. Une interface aux fonctions etrangeres 

Interagir avec des fonctions fournies par le systeme d' exploitation necessite 
une interface aux fonctions etrangeres (foreign function interface ou FFI) 
qui nous permet de communiquer avec le systeme. Pour avoir une utilite 
et une aise d' utilisation maximale, la FFI devrait pouvoir communiquer de 
maniere entierement dynamique avec le syseme, c'est-a-dire sans necessiter 
la generation de code C ou de code compile separement. De plus, pour nos 
besoins particuliers, (ecrire des callbacks et generer des objets COM) nous 
avons aussi besoin de pouvoir transformer des fonctions SML en des pointeurs 
de fonctions qui peuvent etre appeles de C. 

Nous presentons ici F interface minimaliste qui est utilisee pour un 
prototype de notre systeme, avec Fidee qu'elle est assez simple pour etre portee 
sans trop de problemes, puisqu'elle ne depend que tres peu sur la representation 
internes de donnees dans le compilateur SML. 

structure Wffi : sig 

type addr = Word32.word 
type word = Word32.word 
type library 

val alloc : int -> addr 

val free : addr -> unit 

val offset : addr * int -> addr 

val store : addr * word list -> unit 

val read : addr * int -> word list 

val addrToFun : addr -> (word list -> word) 
val funToAddr : (word list -> word) -> addr 

val library : string -> library 
val function : library -> string -> addr 
end 

Lidee de base de F interface est celle de representer F information traversant 
Finterface sous une forme primitive: une representation en mots. Nous aurions 
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pu aussi tout ramener sous forme d' octets, mais etant donne que les arguments 
des fonctions de 1' API qui nous concernent ont tous des grandeurs multiples de 
mots, notre choix nous simplifie la vie. Une fonction etrangere est une fonction 
de type word list -> word, prenant comme argument une liste de mots 
representant les arguments de la fonction. Cette representation accomode le 
passage d'arguments de grandeur de plus d'un mot (des structs, par exemple). 

Le coeur de l'interface est la paire de fonctions funToAddr et 
addrToFun, qui respectivement transforment une fonction de type word 
list -> word (une fermeture) en pointeur de fonction (une addresse), et 
transforment un pointeur de fonction en fonction de type word list -> 
word. En general, ce type d' implantation necessite une methode de generation 
de code-objet a l'execution (runtime code generation), que nous empruntons a 
Fune des FFI existantes de Standard ML of New Jersey [4]. 

Les fonctions library et function permettent de charger une librairie 
dynamique, et d'en extraire des pointeurs de fonction. Par exemple, pour 
acceder a la fonction ShowWindow de la librairie user32 . dll: 

val showWindow = let 

val 1 = Wffi. library ("user32.dll") 
val f = Wf fi . function ( 1 ," ShowWindow" ) 

in 

Wff i . addrToFun (f) 
end 

II y a plusieurs points importants que nous n'abordons pas ici. Tout 
d'abord, le fait qu'il existe plusieurs conventions d'appel (calling conventions) 
possibles, qui determinent si 1' appelant ou l'appele est en charge de depiler les 
arguments lorsqu'un appel de fonction se termine. Nous ne ferons que noter 
que (presque) toutes les fonctions de 1' API Win32 et COM sont implantes avec 
la convention dites Pascal, qui dit que l'appele depile les arguments. Un autre 
point que nous n'allons pas discuter concerne l'ordre dans lequel les elements 
de structures doivent etre empilees. Ces details, aussi importants soient-ils, ne 
feraient que compliquer inutilement la presentation. 

4. Un langage de definition d'interfaces 

Notre but premier etant de fournir a l'utilisateur du langage SML une facon 
d'acceder aux fonctions fournies par F API Win32 et par divers objets COM, il 
est utile d' identifier une notation qui nous permette de specifier l'interface d'un 
systeme d'une maniere independante de la FFI du compilateur SML que nous 
avons sous la main, et de realiser un outil qui nous permettrait de convertir une 
description dans cette notation en une implantation correspondant a la FFI qui 
nous interesse. L utilisation d'une FFI necessitant generalement du verbiage 
important et etant susceptible a des erreurs difficiles a retracer, cette methode 
a l'avantage de centraliser dans F outil la generation de code de support pour 
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F appel de fonctions etrangeres, ainsi que toute decision portant par exemple sur 
la representation des donnees (types de base, types construits tels que structures 
and unions). 

La notation que nous adoptons est naturelle, et Microsoft Futilise deja 
pour decrire l'interface aux objets COM. II s'agit d'IDL (Interface Definition 
Language), un langage derive du modele IDL de [14] utilise par l'OSF pour 
specifier des services RPC. IDL permet de definir des structures de donnees 
semblables a celles de C, et permet de definir des operations d'une maniere 
similaire a C. Une difference importante concerne le fait que chaque parametre 
d'une operation possede un attribut qui decrit si le parametre est in (le 
parametre est utilise pour passer une valeur a F operation), ou out (le parametre 
est utilise pour retourner une valeur de l'operation). LIDL que Foutil accepte 
est en fait une version reduite de 1'IDL pour COM: la base de DCE, sans les 
attributs pour la distribution par RPC, et la base de COM et Automation. 

Voici un example de description IDL pour une librairie hypothetique: 

interface Time { 

typedef struct { 

long sec; 

long usee; 
} timeval_t; 

void gettime ([out] timeval_t *cpu, 

[out] timeval_t *gc, 

[out] timeval_t *sys); 

void timeofday ([out] timeval_t *tod) ; 

} 

Le mode de fonctionnement de notre outil, ML-IDL [10], est represente a 
la Fig. 1. Comme nous Favons dit, e'est un traducteur de description IDL en 
code SML. L outil est parametre par le type de FFI pour laquelle le code doit 
etre genere, et par le mode d' interface desire — un fichier IDL peut decrire 
une librairie statique, une librairie dynamique, une interface COM. Le code 
genere repose sur la capacite d' abstraction du systeme de modules de SML. 
Une signature et un module sont generes pour chaque interface. La signature 
est independante de la FFI visee, et represente l'interface abstraite. Le module 
genere varie selon la FFI visee. 

L'outil ML-IDL est de plus parametre par ce que Ton pourrait appeler 
un "niveau" d' interface. L'idee de base est de representer l'interface vers la 
librairie decrite en IDL de maniere abstraite, en utilisant des types abstraits 
correspondant aux types de base et aux types definis, avec des fonctions 
creant et lisant ces valeurs abstraites, et des fonctions agissant sur ces valeurs 
abstraites correspondant aux fonctions de la librairie. II est possible d'interagir 
avec la librairie de cette maniere, en convertissant "a la main" les valeurs SML 
a passer a la librairie. II est aussi possible de generer automatiquement ces 
conversions, a la maniere de H/Direct [2]. Mais l'utilisation d'une interface 
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Figure 1: L'outil ML-IDL 



abstraite permet d'implanter differents niveaux de generation automatique, 
par exemple en convertissant des valeurs abstraites retournees par la librairie 
de maniere paresseuse. L'outil ML-IDL peut done etre vu comme un 
generalisation de H/Direct dans ce contexte, en ce qu'il permet de multiples 
modes de traduction. Une description complete de l'outil etant impossible, 
nous referons le lecteur vers [10]. 

Pour les besoins de cet article, nous considerons une traduction d'IDL dans 
le style de H/Direct, qui nous donne pour la description IDL donnee plus haut la 
signature suivante. Noter que les parametres out sont retournes comme resultat 
d'operations. 

structure Time : sig 

datatype timeval_t = timeval_t of {sec : Int32.int, 

usee : Int32.int} 

val gettime : unit -> (timeval_t * timeval_t * timeval_t) 

val timeofdat : unit -> timeval_t 
end 



5. Support pour l'API Win32 

L'API Win32 etant fixe, creer une implantation de l'API devient simplement 
une question de produire sa description IDL. Avec cette description, nous 
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pouvons utiliser l'outil ML-IDL pour generer une implantation de l'API 
compatible avec la FFI du systeme utilise. 

L'appendice A presente un extrait de la description IDL de l'API Win32 
que nous utilisons. L'appendice B presente la signature generee par ML-IDL 
correspondant a F extrait. 

Nous ne montrons pas le module genere correspondant a l'implantation 
de la signature par la FFI de la section 3 pour des raisons d'espace. Plutot 
qu'aller dans les details, notons quelques aspects de la programmation Win32 
en SML par le biais d'un exemple. L'appendice C presente un programme 
Win32 ecrit en SML via l'interface de l'API Win32. II s'agit du logo 
de SML/NJ rebondissant a Finterieur d'une fenetre. Le code, une simple 
traduction du programme C correspondant, montrent certaines caracteristiques 
de la programmation Win32 en SML. 

Comme nous l'avons indique a la Section 2, la structure d'un programme 
inclut la definition de fonctions en charge de traiter les messages addresses 
aux differentes fenetres de 1' application. Nous appelons ces fonctions des 
wndprocs. De telles wndprocs sont utilisees lors de l'enregistrement de la 
classe d'une fenetre. Une wndproc est un des elements de la struct passee 
comme argument a la fonction W32 . User . RegisterClassExA. L'outil 
ML-IDL genere les abstractions necessaires pour nous permettre de passer une 
fonction de type 

W32.hwnd * int * Word32 . word * Word32.word -> int 

comme wndproc a la fonction RegisterClassExA. Etant donne que la 
struct passee comme argument a la fonction RegisterClassExA de l'API 
s' attend a recevoir un pointeur vers une fonction comme element correspondant 
a la wndproc, notre code SML genere se doit de convertir la fonction SML en 
pointeur de fonction. Ceci est acheve dans notre FFI en utilisant la fonction 
Wf f i . funToAddr. 

Une consequence de 1' utilisation d'une wndproc comme structure centrale 
d'un programme Win32 est particulierement ennuyante. La wndproc est 
appelee une fois pour chaque message recu de la fenetre correspondante. Ce 
qui veut dire que si des donnees doivent etre preservers d'un message a F autre, 
par exemple des donnees sur les dimensions de la fenetre, une cellule ref 
doit etre allouee pour F information. Ce qui conduit a du code extremement 
imperatif, avec beaucoup de variables globales. Largument n'est pas si grave 
pour Standard ML qui possede un support respectable pour la programmation 
imperative, mais rend F expression de programmes Win32 natifs en Haskell (ou 
tout langage fonctionnel pur) problematique. 

II est possible de contourner ce probleme en utilisant Concurrent ML [11]. 
Nous pouvons exprimer notre wndproc de la facon suivante: 

local 
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val ch = channel (W32 . nullHwnd, 
0, 

OwO : Word32 .word, 
OwO : Word32.word) 
val retch = channel (0) 

in 

fun WndProc (hwnd, msg, wparam, lparam) = 

(send (ch, (hwnd, msg, wparam, lparam) ) ; 
recv (retch) ) 

fun WndProc' (} = let 
val loop (state) = let 

val (hwnd, msg, wparam, lparam) = recv (ch) 

in 

(* body *) 
end 

in 

loop (initial_state) 
end 
end 

Le corps de la boucle interne de WndProc' doit communiquer la valeur de 
retour par le canal retCh, et s'appeler recursivement avec un nouvel etat 
(contenant, par exemple, les dimensions de la fenetre courante). Le code 
d' initialisation de l'application doit appeler spawn (WndProc' ) pourcreer 
la thread qui va ecouter sur le canal ch. 

II ne reste qu'une question: pourquoi nous attardons-nous a vouloir 
programmer a ce niveau si bas? Apres tout, la plupart des programmeurs 
d' applications Win32 ne programmentpas directement avec 1' API Win32, mais 
plutot avec une librairie de classes C++ telle que MFC ou OWL. En fait, la 
question se pose de meme en C++: pourquoi devrait-on connaitre 1' API Win32 
s'il existe des librairies comme MFC et OWL? La reponse dans les deux cas 
est similaire: parce ce qu'aucun vernis de haut-niveau ne peut traiter tous les 
cas possibles. Si quelque chose de special doit etre effectue, il est souvent 
necessaire de revenir au niveau le plus bas, c'est-a-dire l'API Win32. II est 
done imperatif de pouvoir fonctionner completement a ce niveau. II est aussi 
interessant de fournir une interface a un niveau tel qu'il est possible d'utiliser 
directement des textes pedagogiques existant. II est en effet facile de traduire 
des programmes tires de [8] et de les implanter en SML avec l'interface derivee 
plus haut. Par exemple, l'exemple de l'appendice C est tire directement du 
chapitre 7 de [8]. 



6. Support pour COM 

II a deux problemes relativement distincts relies a la programmation COM: 
utiliser des objets COM lors de la programmation d' applications Win32, 
et l'implantation d'objets COM utilisable par d'autres applications. Nous 
considerons ces problemes separement. 
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6.1. Utiliser des objets COM en SML 

Le probleme le plus simple a resoudre est celui d'utiliser des objets COM dans 
un programme SML. Etant donne un objet COM que nous voulons utiliser avec 
sa description IDL, nous pouvons utiliser l'outil ML-IDL pour generer du code 
qui va pouvoir creer des instances de cet objet. 

Nous avons tout d'abord besoin d'une petite librairie COM fournissant 
1' infrastructure necessaire. Les fonctions de cette librairie se retrouvent 
principalement dans la librairie dynamique ole32.dll, mais nous ne 
voulons pas utiliser la methode de la section precedente pour implanter cette 
interface, puisque nous voudrions un systeme de type plus sophistique pour 
traiter les interfaces COM. Voici la signature d'une partie de la librairie COM 
dont nous avons besoin. 

structure Com : sig 

type CLSID 

type 'a I ID 

type ' a interface 

type IUnknown 

val IUnknown : IUnknown IID 

val CoCreatelnstance : CLSID -> 'a IID -> 'a interface 
end 

La fonction CoCreatelnstance prend comme argument le CLSID 
de Fobjet que nous voulons creer, et l'interface que nous desirons obtenir. 
Nous utilisons des types-temoins (comme dans [9]) pour guarantir le 
fait que CoCreatelnstance cree une interface (de type interface) 
correspondant a F IID demande. Chaque interface generee par le compilateur 
IDL se doit d'inclure un type-temoin pour l'interface. 

Par exemple, considerons un objet COM Bar qui possede une interface IX 
et IY (toutes deux derivees de IUnknown) avec une fonction FooX dans IX 
et une fonction FooY dans I Y. La signature generee par l'outil IDL a la forme 
suivante. 

structure Bar : sig 

val BarCLSID : Com. CLSID 

structure IX : sig 
type IX 

val IX : IX Com.iid 

val Querylnterf ace : IX Com . interface -> 'a Com. IID -> 'a Com . interface 
val FooX : IX Com . interface -> unit -> unit 
end 

structure IY : sig 
type IY 

val IY : IY Com.iid 
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val Query Interface : IY Com . interface -> 'a Com.IID -> 'a Com. interface 
val FooY : IY Com . interface -> unit -> unit 
end 

end 

Notons que les fonctions AddRef et Release de Finterface IUnknown 
ne sont pas incluses dans le code genere, puisqu'elles ne sont jamais utilisees 
par l'utilisateur dans l'implantation SML. 

Dans notre prototype utilisant la FFI decrite a la Section 3, vine interface 
est simplement un pointeur vers un bloc de memoire contenant les pointeurs de 
fonctions. Extraire une methode d'une interface correspond done simplement 
a extraire le pointeur correspondant et de convertir le pointeur de fonction en 
une fermeture via Wf f i . addrToFun. 

type 'a interface = wffi.addr 

fun getMethod ( interface, index) = let 
val i' = Wffi. offset (interface, index) 
val p = hd (Wffi. read (i',1)) 

in 

addrToFun (p) 
end 

6.2. Creation d'objets COM en SML 

A priori, e'est le probleme le plus ardu. Mais la difficulte est principalement 
due a 1' architecture du compilateur que nous utilisons. Le probleme peut se 
subdiviser encore une fois en deux problemes distincts. Tout d'abord, nous 
devons pouvoir creer des objets COM en SML. Ensuite, nous devons pouvoir 
distribuer ces objets COM pour que d'autres applications puissent les utiliser 
(programmation d'un serveur). 

Creer des objets COM est fondamentalement simple, mais demande de 
la discipline. Comme on se le rappelle, un objet COM est simplement un 
ensemble d'interfaces, toutes derivees de Finterface IUnknown. Creer un 
objet COM correspond a determiner un ensemble d'interfaces a supporter, 
implanter les methodes, et creer les interfaces elles-memes, en creant un 
tableau en memoire et en y placant les pointeurs de fonctions correspondants. 
Comment construire une interface? Supposons que nous voulons implanter 
Fobjet COM Bar decrit a la sous-section precedente. Voici un extrait de code 
utilisant notre FFI de la section 3. 

fun fooX [] = print "executing FooX" 

fun fooY [] = print "executing FooY" 

fun makelnterf ace (1) = let 

val 1' = [querylnterf ace, addRef, release] @1 

val i = Wffi. alloc (length (1')) 

val _ = Wffi. store (i, map Wf f i . f unToAddr 1') 
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val p = wffi. alloc (1) 
val _= wffi . store (p, [i] ) 

in 

P 

end 

val IUnknown = makelnterf ace [] 
val IX = makelnterf ace [fooX] 
val IY = makelnterf ace [fooY] 



La fonction make Inter face prend une liste de fonction SML a inserer dans 
F interface, et construit le bloc memoire, incluant les fonctions faisant partie de 
Finterface IUnknown. La fonction query Interface, non montree, est en 
charge de determiner quelle interface retourner (IUnknown, IX ou IY), selon 
FIID passe. 

La creation d'un serveur, c'est-a-dire d'un distributeur d'objets COM, est 
plus compliquee. Tout d'abord, une usine de classes (class factory) doit etre 
implantee. II s'agit la d'un objet COM ayant pour fonction de creer les objets 
COM implantes par le composant. II n'y a pas d' interface exigee pour une 
usine de classes, mais Finterface typique est l'interface IClassFactory. 
II existe aussi une interface IClassFactory2 qui supporte des licenses 
et des authorisations. Un client qui utilise des objets COM fournis par un 
serveur implantant une usine de classes derivant de IClassFactory peut 
utiliser la fonction CoCreatelnstance de l'API Win32 pour creer les 
objets directement. Si une autre interface est utilisee, le client doit utiliser 
la fonction CoGetClassOb ject de l'API Win32, qui extrait l'usine de 
classes du composant et laisse au client le soin d' appeler la fonction de creation 
requise. II faut noter que CoCreatelnstance est implante en fonction de 
CoGetClassOb ject. 

Deux types de serveurs sont possible: in-proc et out-proc. Un serveur in- 
proc (voir Fig. 2) est une librairie dynamique qui implante le code des objets 
COM fournis par le composant. Une fonction DllGetClassOb ject doit 
etre exportee par la librairie, et cree l'usine de classes pour le composant 
(c'est la fonction qui est appelee par CoGetClassOb ject). D'autres 
fonctions, telles que DllRegisterServer, DllUnregisterServer 
et DllCanUnloadNow doivent etre implantees pour l'enregistrement et la 
liberation de la librairie dynamique. Le probleme de cette approche dans 
notre cas est que creer des librairies dynamiques avec Standard ML of New 
Jersey n'est pas reellement supporte. Un nouveau runtime system est en 
developpement qui permettra la creation de librairies dynamiques et done de 
serveurs in-proc. 

L autre type de serveur, un serveur out-proc, est un serveur implante par 
un executable (un exe). Si une librairie dynamique fournissant un composant 
se doit d'exporter une fonction DllGetClassOb ject qui retourne l'usine 
de classes du composant, un serveur exe doit manuellement enregistrer ses 
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Figure 2: Serveur in-proc 

usines de classes en appelant la fonction CoRegisterClassOb ject de 
FAPI Win32. Rien de bien complique jusqu'a present. Le probleme majeur, 
c'est que le systeme necessite une librairie dynamique qui joue le role d'un 
proxy (voir Fig. 3). Le proxy communique avec une instance de lui-meme par 
le biais d'un protocole LPC {Local Procedure Call). Construire cette librairie 
dynamique est long et offre d'innombrables possibilites d'erreur. 

Le compilateur MIDL de Microsoft, qui prend comme source le fichier 
IDL correspondant au composant fourni par le serveur, genere du code C 
correspondant au proxy. II est possible d'utiliser ce compilateur ainsi qu'un 
compilateur C pour creer le proxy. II est regrettable par ailleurs que cela nous 
force a abandonner notre modele de garder la creation de programmes Win32 
completement centree sur des programmes SML. Nous etudions presentement 
des methodes alternatives pour achever le meme effet. 

Nous notons en terminant qu'un serveur out-proc peut etre utilise 
naturellement comme un serveur sur reseau en utilisant le mecanisme DCOM. 
Ceci ne necessite aucune modification au code SML du serveur. 

7. Conclusion 

Nous decrivons dans cet article une infrastructure pour la programmation 
Win32 sous le langage fonctionnel Standard ML. Un prototype existe pour 
le compilateur Standard ML of New Jersey, et sert comme base experimentale 
pour explorer differentes idees. 

Ou tout cela nous conduit-il? La majorite des infrastructures pour la 
programmation Win32 sous des langages tels que C et C++ introduisent des 
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Figure 3: Serveur out-proc 



librairies de haut-niveau qui reduisent la complexite de la programmation, 
telles que les librairies de classes C++ MFC et OWL. Pour Standard ML, une 
direction interessante consiste en l'implantation d'une librairie dans le style de 
eXene [3], une interface graphique pour le systeme X, qui utilise Concurrent 
ML [11] pour traiter le parallelisme implicite des interfaces graphiques. Un 
programme a long terme serait de generaliser ces differentes librairies et de 
fournir une infrastructure de programmation graphique uniforme sur differents 
systemes, tout en preservant les caracteristiques fondamentales des differents 
systemes (le look-and-feel). Bien sur, ceci n'addresse que le probleme 
de la programmation graphique, et laisse ouvert le probleme d'utiliser des 
composants de type COM (ou CORBA) d'une maniere generalisee. 

Une remarque finale: notre infrastructure est base sur le compilateur 
Standard ML of New Jersey, mais n'est certainement pas restreinte a ce 
systeme. En ajoutant a Foutil ML-1DL un backend qui genere du code pour la 
FFI de MLWorks ou de Ocaml [5], nous pouvons fournir la meme interface et 
les memes capabilites a ces differents systemes. Par ailleurs, du a la nature des 
FFI de ces systemes, nous devrons probablement aussi generer du code C pour 
pouvoir implanter l'equivalent de notre fonction Wf f i . f unToAddr. 
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A. Extrait de la description IDL de l'API Win32 



// 

// IDL description of Win32 API 
// 



sml_name ("W32"); 



typedef int INT; 
typedef int HANDLE ; 
typedef int HRESULT; 



typedef HANDLE HWND; 

typedef HANDLE HDC; 

typedef boolean BOOL; 

typedef [string] char *STRING; 

typedef [string] wchar_t *WSTRING; 

typedef int *WNDPROC ([in] HWND hwnd, [in] INT msg, 

[in] INT wParam, [in] INT lParam) ; 

typedef struct _WNDCLASSEX { // wc 

UINT cbSize; 

int style; 

WNDPROC lpfnWndProc; 

int cbClsExtra; 

int cbWndExtra; 

HANDLE hlnstance; 

HANDLE hlcon; 

HANDLE hCursor; 

HANDLE hbrBackground; 

STRING IpszMenuName; 

STRING IpszClassName; 

HANDLE hlconSm; 
} WNDCLASSEX; 

typedef struct tagPOINT { // pt 

INT x; 

INT y; 
} POINT; 

const char *IDI_APPLICATION = "#32512"; 
const char *IDI_HAND = "#32513"; 
const char *IDI_QUESTION = "#32514"; 
const char *IDI_EXCLAMATION = "#32515"; 



const char *IDC_ARROW = "#32512"; 
const char *IDC_IBEAM = "#32513"; 
const char *IDC_WAIT = "#32514"; 
const char *IDC_CROSS = "#32515"; 



typedef enum { 
CS_VREDRAW = 1, 
CS_HREDRAW = 2, 



CW_USEDEFAULT = 0wx80000000, 



WS_OVERLAPPED 
WS_POPUP = 
WS_CHILD = 
WS_MINIMIZE = 
WS_VISIBLE = 



= OwxOOOOOOOO, 
0wx80000000, 
0wx40000000, 
0wx20000000, 
OwxlOOOOOOO, 
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} OPTS; 

typedef enum { 
SW_HIDE = 0, 
SW_SHOWNORMAL = 1, 
SW_NORMAL = 1, 
SW_SHOWMINIMIZED = 2, 
SW_SHOWMAXIMIZED = 3, 
SW_MAXIMIZE = 3, 



} CONSTS; 

typedef enum { 

WM_NULL = OwxO, 

WM_CREATE = Owxl, 

WM_DESTROY = 0wx2, 

WM_MOVE = 0wx3, 

WM_SIZE = 0wx5, 

WM_SETFOCUS = 0wx7, 

WM_PAINT = Owxf, 

WM_TIMER = 0wxll3, 

WM_HSCROLL = 0wxll4, 

WM_VSCROLL = 0wxll5, 



} WM; 



[sml_source ("user32.dll"}] 
interface User { 

// classes 

int RegisterClassExA ([in,ref] WNDCLASSEX *wndclass); 

BOOL UnregisterClassA ([in] STRING className, 
[in] HANDLE hlnstance) ; 

// window handling 

HWND CreateWindowExA ([in] INT dwExStyle, 

[in] STRING classname, 

[in] STRING windowname, 

[in] INT style, 

[in] INT x, 

[in] INT y, 

[in] INT width, 

[in] INT height, 

[in] HWND parent, 

[in] HANDLE menu, 

[in] HANDLE hinstance, 

[in] LPVOID param) ; 

BOOL ShowWindow ([in] HWND hwnd, 

[in] INT cmdshow) ; 

BOOL UpdateWindow ([in] HWND hwnd) ; 

// painting 

HDC BeginPaint ([in] HWND hwnd, 

[out,ref] PAINTSTRUCT *ps); 
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BOOL EndPaint ([in] HWND hwnd, 

[in,ref] PAINTSTRUCT *ps); 

/ / icons 

HANDLE LoadlconA ([in] HANDLE h, 

[in] STRLNG name) ; 

} 



[sml_source ("gdi32.dll")] 
interface Gdi { 

BOOL LineTo ([in] HDC hdc, 

[in] int nXEnd, 
[in] int nYEnd) ; 

BOOL PolyLineTo ([in] HDC hdc, 

[in,size_is (cPoints) ] POLNT *lppt, 
[in] LNT cPoints) ; 

} 



B. Extrait de la signature pour l'API Win32 



* This file was automatically generated by ml-idl 

* (Tue Dec 8 09:41:24 1998) 

signature W32_SIG = 
sig 
(* 

* Pervasives 
*) 

type ' a pointer 

val null : ' a pointer 

val free : ' a pointer -> unit 



val IDI_APPLICATION : String . string 
val IDI_HAND : St ring . st ring 
val IDI_QUESTION : String . string 
val IDI_EXCLAMATION : St ring . st ring 

val IDC_ARROW : St ring . st ring 
val IDC_IBEAM : St ring . st ring 
val IDC_WAIT : String . string 
val IDC_CROSS : String . string 

type INT = Int32.int 
type HANDLE = Int 32. int 
type HRESULT = Int32.int 

type HWND = HANDLE 
type HDC = HANDLE 
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type BOOL = Bool.bool 

type STRING = String . string 

type WSTRING = String . string 



type WNDPROC = ( (HWND * INT * INT * INT) -> Int32.int) 

datatype WNDCLASSEX = WNDCLASSEX of {cbSi ze : UINT , 

style : Int32 . int, 
lpf nWndProc : WNDPROC , 
cbClsExtra : Int 32 . int, 
cbWndExtra : Int32 . int, 
hlnstance: HANDLE, 
hlcon: HANDLE, 
hCursor: HANDLE, 
hbrBackground: HANDLE, 
IpszMenuName : STRING, 
IpszClassName : STRING, 
hlconSm : HANDLE} 

datatype POINT = POINT of {x : INT, y : INT} 



datatype OPTS 



CS_VREDRAW 

CS_HREDRAW 

CW_USEDEFAULT 

WS_OVERLAPPED 

WS_POPUP 

WS_CHILD 

WS_MINIMIZE 

WS_VISIBLE 



structure OPTS : sig 

val tolnt : OPTS -> Int32. 

val fromlnt : Int32.int 
end 



int 

OPTS option 



datatype CONSTS 



SW_HIDE 

SW_SHOWNORMAL 

SW_NORMAL 

SW_SHOWMINIMIZED 

SW_SHOWMAXIMIZED 

SW_MAXIMIZE 



structure CONSTS : sig 

val tolnt : CONSTS -> Int32.int 

val fromlnt : Int32.int -> CONSTS option 

end 



datatype WM 



structure WM 
val tolnt 
val fromlnt 

end 



WM_NULL 

WM_CREATE 

WM_DESTROY 

WM_MOVE 

WM_SIZE 

WM_SETFOCUS 

WM_PAINT 

WM_TIMER 

WM_HSCROLL 

WM_VSCROLL 

: sig 

WM -> Int32.int 

: Int32.int -> WM option 



structure User : sig 

val RegisterClassExA : WNDCLASSEX -> Int 32. int 
val UnregisterClassA : (STRING * HANDLE) -> BOOL 
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val CreateWindowExA : (INT * STRING * STRING * INT * 
INT * INT * INT * INT * HWND * 
HANDLE * HANDLE * LPVOID) -> HWND 

val ShowWindow : (HWND * INT) -> BOOL 

val UpdateWindow : HWND -> BOOL 

val BeginPaint : HWND -> (PAINTSTRUCT * HDC) 
val EndPaint : (HWND * PAINTSTRUCT) -> BOOL 
val LoadlconA : (HANDLE * STRING) -> HANDLE 
end 

structure Gdi : sig 

val LineTo : (HDC * Int32.int * Int32.int) -> BOOL 
val PolyLineTo : (HDC * POINT list * INT) -> BOOL 

end 



C. Exemple de programme Win32 



structure BounceWin = struct 
val zero = : Int32 . int 



val ballTimer 



Int32 .int 



val moveRate = 10 : Int32 . int 
val timerRate - 20 : Int32.int 



val hlnstance = ref (zero) 



val 
val 
val 
val 
val 
val 
val 
val 
val 
val 
val 



cxClient = ref 
cyClient = ref 
xCenter = ref ( 
yCenter = ref ( 
cxTotal - ref ( 
cyTotal - ref ( 
cxRadius = ref 
cyRadius = ref 
cxMove = ref ( z 
cyMove = ref ( z 
hBitmap = ref ( 



(zero) 

(zero) 

zero) 

zero) 

zero) 

zero) 

(zero) 

(zero) 

ero} 

ero) 

zero) 



fun destroy (hwnd) = 

(W32 .User .KillTimer (hwnd, ballTimer ) ; 
if ( IhBitmap <> 0) 

then ignore (W32 . Gdi . DeleteOb ject ( ! hBitmap) } 
else ( ) ; 

W32 .User .PostQuitMes sage (0) ; 
zero) 

fun size (hwnd, xsize, ysize) = 
(cxClient := xsize; 
cyClient := ysize; 
xC enter : = xsize div 2 ; 
y Center : = ysize div 2 ; 
cxMove := moveRate; 
cyMove := moveRate; 

cxTotal := 158; (* from PAINT *} 
cyTotal := 131; 
cxRadius := 118 div 2; 
cyRadius := 90 div 2; 
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if ( ! hBitmap <> 0) 

then ignore (W32 . Gdi . DeleteOb ject (IhBitmap)) 
else ( ) ; 

hBitmap := W32 . User . LoadlmageA 
( , " smln j . bmp" , 
W32 .CONSTS.toInt 
(W32 . IMAGE_BITMAP) , 

0, 0,W32U.or [W32 . LR_LOADFROMFILE ] ) ; 

zero) 

fun timerBall (hwnd) = 

if (! hBitmap = 0} then zero 
else let 

val hdc = W32 .User.GetDC (hwnd) 

val hdcMem = W32 . Gdi . CreateCompatibleDC (hdc) 

in 

W32 . Gdi . SelectOb ject (hdcMem, I hBitmap); 
W32 . Gdi .BitBlt (hdc, 

(IxCenter) - (IcxTotal) div 2, 

(lyCenter) - (IcyTotal) div 2, 

IcxTotal, IcyTotal, 

hdcMem, 0,0, 

W32 . CONSTS . tolnt (W32 . SRCCOPY) ) ; 
W32 .User .ReleaseDC (hwnd, hdc); 
W32 . Gdi .DeleteDC (hdcMem); 
xCenter :- (IxCenter) + (IcxMove); 
yCenter := (lyCenter) + (IcyMove); 

if ((IxCenter) + (IcxRadius) >= (IcxClient)) orelse 
((IxCenter) - (IcxRadius) <= 0) 
then cxMove := ~{ IcxMove) 
else ; 

if ((lyCenter) + (IcyRadius) >= (IcyClient)) orelse 

((lyCenter) - (IcyRadius) <= 0) 

then cyMove :- ~ (IcyMove) 
else () ; 

zero 

end 

fun timer (hwnd, timerlD) = 
if (timerlD = ballTimer) 

then timerBall (hwnd) 
else zero 



fun create (hwnd) = let 

val hdc = W32 .User.GetDC (hwnd) 

in 

W32 . User . ReleaseDC (hwnd, hdc); 

W32 . User . SetTimer (hwnd, ballTimer, timerRate, NONE) ; 
zero 
end 

and wndproc (hwnd, Msg, wParam, lParam) = 
case (W32 .WM. fromlnt (Msg)) 

of SOME ( W3 2 . WM_CREATE ) => create (hwnd) 
SOME (W32 .WM_SIZE) => 

size (hwnd, W32U.loWord (lParam), W32U.hiWord (lParam)) 
SOME (W32 . WM_DESTROY) => destroy (hwnd) 
SOME (W32 .WM_TIMER) => timer (hwnd, wParam) 
_ => W32 . User . Def WindowProcA (hwnd, Msg, wParam, lParam) 

fun winmain (hinstance, _} = let 
val _ = hinstance := hinstance 
val szAppName = "BouncingSMLNJ" 

val hicon = W32 . User . LoadlconA (0, W32 . IDI_APPLICATION) 
val hcursor = W32 . User . LoadCursorA (0, W32 . IDC_ARROW) 
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Programmation d' applications Win32 



val hbrush - W32 . Gdi . GetStockOb ject (W32 . CONSTS . tolnt (W32 .WHITE_BRUSH) ) 
val wndclassex - W32 .WNDCLASSEX 
{cbSize - 48, 

style - W32U.or [W32 . CS_HREDRAW, 
W32.CS_VREDRAW] , 

Ipf nWndProc = wndproc, 

cbClsExtra - 0, 

cbWndExtra = 0, 

hlnstance = hinstance, 

hlcon = hicon, 

hCursor = hcursor , 

hbrBackground = hbrush, 

IpszMenuName = " " , 

lps zClassName = s zAppName, 

hlconSm = hicon} 
val _ = W32.User. RegisterClassExA (wndclassex) 
val hwnd = W32 . User . CreateWindowExA 
(0, 

s zAppName, 
"Bouncing SML/NJ", 

W32U . or [ W32 . WS_OVERLAPPEDWINDOW] , 

W32U . or [W32 . CW_USEDEFAULT ] , 

W32U . or [W32 . CW_USEDEFAULT ] , 

500, 

300, 

0, 

0, 

hinstance , 
W32 . null) 

fun f () = (W32 .User . ShowWindow (hwnd, 1) ; 

W32 . User . UpdateWindow (hwnd) ; 

( * the following call is required because creating 

* the window from the interactive loop seems to 

* not put it on top 

*) 

W32 . User . SetForegroundWindow (hwnd) ; 
W32U . simpleMsgLoop ( ) ) 

in 

W32U.checkHwnd (hwnd, f ) ; 

W32 . User . UnregisterClassA (szAppName, hinstance) ; 

end 

fun doit () = RunW32 .doit (winmain) 
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